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ABSTRACT 


I 


Current  trends  in  the  computerization  of  specialized  custom  chemi- 
cal instrumentation  indicate  the  increasing  utilization  of  dedicated 
microprocessors.  Conventional  software  techniques  often  possess  serious 

I 

limitations  in  regard  to  initial  development  effort,  execution  speed,  I 

flexibility,  and/or  hardware  required.  A high-level  "interpretive  com-  I 

piler"  software  package  CONVERS  is  described  which  offers  numerous 
advantages  compared  to  conventional  approaches  including  high  speed 
operation,  high  level  I/O,  language  flexibility,  superior  memory  effi- 
ciency and  a variety  of  other  desirable  characteristics. 


Advanced  Software  Concepts  for  Employing 
Microcomputers  in  the  Laboratory 


t 


Scott  B.  Til  den  and  M.  Bonner  Denton 
Department  of  Chemistry 
University  of  Arizona 
Tucson,  Arizona  85721 

While  a proliferation  of  commercial  chemical  instrumentation  is 
appearing  today  employing  microprocessors  for  a variety  of  control  and 
data  reduction  applications,  the  great  potential  of  microprocessors  has 
not  been  exploited  extensively  for  individual  custom  applications.  The 
primary  reason  for  this  phenomenon  is  altogether  too  clear— microproces- 
sor software  is  either  difficult  to  develop  or  inefficient  in  memory 
requirements  and  speed.  This  problem  is  even  more  important  in  situa- 
tions rec|uiring  constant  software  modification.  Initially,  most  instru- 
ment manufacturers  utilized  cross  assemblers  supported  on  large  "number 
cruncher"  computers  to  generate  the  required  machine  code  binary  program. 
More  recently,  the  trend  has  been  toward  the  use  of  a "developmental 
system"  (at  a cost  comparable  to  a moderate  minicomputer--the  authors 
use  the  term  "mini"  in  contrast  to  "micro"  reluctantly  because  of  the 
ever  increasing  overlap  in  computing  capability)  to  write  and  debug 
assembly  level  programs  which  are  subsequently  Converted  to  binary  and 
incorporated  into  an  instrument  in  the  form  of  "read  only  memory"  (ROM). 
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While  this  approach  has  proven  cost  effective  for  high  volume  mass  pro- 
duced applications,  it  possesses  serious  limitations  for  system  updates 
and  custom  applications.  Additionally,  the  ability  to  program  effi- 
ciently at  the  assembly  level  is  a talent  requiring  a significant  expen- 
diture of  time  to  develop. 

During  the  past  several  years,  a virtual  deluge  of  sophisticated, 
flexible,  high  performance  computer  hardware  has  been  introduced  primarily 
aimed  at  a rapidly  growing  "hobbyist"  market,  flanufacturers  quickly 
realized  that  to  sell  the  public  hardware,  some  form  of  reasonably  high 
level  software  must  be  made  available.  A variety  of  BASIC  interpreters, 
ranging  from  rather  "dumb"  to  "quite  intelligent"  have  since  evolved. 

The  more  intelligent  BASIC  interpreters  have  several  highly  attractive 
attributes  for  "hobbyist"  applications.  The  language  is  both  easy  to 
master  and  conversational.  Error  and  caution  messages  are  provided  as 
aids  during  programming. 

Uhy  not  apply  the  "hobbyist"  technology  toward  the  implementation 
of  custom  laboratory  systems?  Many  investigators  have  and,  no  doubt, 
many  more  will  take  this  approach.  However,  BASIC  interpreters  possess 
serious  limitations  in  terms  of  system  speed,  flexibility,  and 
input/output  (I/O)  capabilities.  In  BASIC,  each  command  must  first  be 
interpreted  and  then  executed  (see  Figure  1).  In  many  cases,  the  inter- 
pretation process  takes  much  more  time  than  the  actual  execution.  This 
problem  is  compounded  by  tlie  fact  that  commands  interpreted  in  the  past 
must  be  re-interpreted  each  time  they  are  used  causing  iterative  pro- 
grams to  bo  very  slow.  While  speed  is  often  not  a serious  limitation 
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in  playing  computer  games,  laboratory  applications  requiring  high  speed 
data  acquisition  and/or  data  manipulation  are  common.  Additionally, 
the  more  intelligent  BASICS  make  very  inefficient  use  of  memory  often 
requiring  a minimum  of  12  or  16  K bytes  (twelve  or  sixteen  thousand 
eight  bi t words). 

In  contrast  to  interpreters,  high  level  compilers,  such  as  FORTRAN, 
offer  a much  faster  "run  time"  execution  speed.  This  is  accomplished 
through  generation  of  the  required  machine  code  during  a series  of  pro- 
gramming operations.  Compilers  using  FORTRAN,  which  are  designed  to 
run  on  many  minicomputers  and  some  micros,  often  first  transform  user 
symbolic  source  code  into  assembly  code.  An  assembler  program,  sub- 
sequently, transforms  this  into  the  required  machine  code.  This  ready- 
to-run  machine  code  is  often  loaded  along  with  a run  time  package  which 
executes  in  the  manner  shown  in  Figure  2.  While  this  approach  greatly 
improves  execution  speed,  the  need  for  loading  several  different  soft- 
ware routines  increases  the  "hassle"  associated  with  editing  and  debugging. 
Thus,  this  makes  some  form  of  mass  memory,  such  as  a disk  or  magnetic  tape, 
almost  mandatory.  Additionally,  I/O  algorithms  generally  must  be  im- 
plemented in  assembly  level  code! 

One  obvious  question  immediately  arises — why  not  incorporate  the 
most  desirable  characteristics  of  both  interpreters  and  compilers  into 
a single  language?  Additionally,  due  to  the  unique  requirements  found 
in  many  applications,  why  not  allow  the  programmer  additional  flexibility 
by  providing  him  with  the  ability  to  actually  develop  his  own  individual 
modifications  and  additions  to  the  language  itself?  Other  desirable 
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features  would  include  high  memory  efficiency,  high  level  I/O  programming, 
ease  of  understanding  the  language's  "inter-workings"  and  the  ability 
to  be  transferred  from  one  CPU  to  another  with  minimum  effort. 

During  the  past  two  years,  a different  approach  to  software  has 
been  taking  place  at  the  University  of  Arizona  referred  to  as  an  "Inter- 
pretive Compiler"  called  CONVERS.  This  package,  which  is  conceptually 
similar  to  the  FORTH  language  currently  being  used  in  several  minicom- 
puter-astronomical applications  (1),  is  able  to  provide  many  of  the 
desirable  features  found  in  both  interpreters  and  compilers  by  separating 
the  compile  and  execute  states  (as  a compiler  does)  while  maintaining  a 
resident  user  interactive  and  conversation  executive  which  oversees  sys- 
tem operation.  The  ability  to  realize  such  advanced  software  capabili- 
ties in  a very  modest  amount  of  memory  (less  than  4 K bytes  on  an  8080 
based  micro)  is  the  direct  result  of  exploiting  threaded  code  programming 
techniques  (see  Figure  3).  The  approach  involves  highly  efficient  use 
of  simple  macroinstructions  to  build  more  complex  subroutines  which  are 
recombined  with  additional  macroinstructions  to  form  super  subroutines. 
This  process  of  combining  previously  defined  modules  to  form  ever  in- 
creasingly sophisticated  routines  for  performing  the  task  at  hand  is 
the  essence  of  threaded  code  programming.  Uhen  initially  loaded  and 
running,  CONVERS  acts  much  like  an  interpreter,  i .e.  it  is  conversational, 
ready  to  either  execute  a previously  programmed  algorithm  or  accept  a 
now  one.  However,  in  contrast  to  BASIC,  when  a now  program  is  being 
entered  under  CONVERS,  it  is  immediately  transformed  into  binary  machine 
code  or  to  the  binary  starting  addresses  of  other  previously  entered 
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and  compiled  machine  code  programs.  During  this  process,  the  operator 

is  kept  informed  of  the  status  of  the  program  by  a series  of  error  and 

diagnostic  messages.  When  the  new  program  has  been  completed,  it  is 

entered  in  a program  library  or  dictionary, which  is  constantly  building  ip  from  lowmanory 

(see  Figure  4).  If  the  operator  now  wants  to  execute  this  program,  he 

can  request  it  from  his  terminal.  A dictionary  search  will  begin  at 

the  last  entry  and  progress  until  the  requested  program  is  located. 

Once  located,  the  requested  program  will  run  in  its  entirety  without 
need  for  any  additional  dictionary  searches.  For  example,  let  us  assume 
an  algorithm,  called  ACQUIRE,  has  been  programmed  to  take  data  from  some 
hypothetical  experimental  system.  When  ACQUIRE  is  requested  from  the 
terminal,  a dictionary  search  is  initiated.  The  program  named  ACQUIRE 
(see  Figure  5),  once  located,  contains  the  starting  addresses  of  a series 
of  previously  de'ined  modules  which  implement  the  various  steps  necessary 
to  perform  the  desired  experiment.  For  example,  the  module  SCAN  which 
might  be  intended  to  scan  a monochromator's  wavelength  in  some  desired 
manner  has  been  previously  defined  and  tested.  This  ability  to  easily 
test  each  module  separately  and  then  efficiently  combine  a series  of 
modules  to  perform  a more  complex  function,  test  this  function, 
and  then  employ  it  in  a vastly  iiwre  complex  function,  etc.,  i.e.  test- 
ing each  step  as  the  threaded  code  is  made  increasingly  complex,  is  a 
major  factor  contributing  to  the  speed  with  which  software  can  be  developed 
using  CONVERS.  Use  of  a software  stack  also  contributes  tov/ard  improved 
memory  efficiency  and  simplified  programming. 
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The  stack  is  an  area  of  memory  set  aside  to  handle  parameters, 
data  numbers,  etc.  One  of  the  primary  advantages  of  the  stack  is  that 
entries  can  leave  temporary  parameters  on  the  stack  without  having  to 
assign  specific  memory  locations  to  store  them.  This  not  only  can  save 
considerable  memory,  but  also  allov/s  programs  to  be  easily  relocatable 
since  one  algori thm  need  only  know  that  a previous  routine  left  so  many 
words  of  data,  etc.  on  the  stack.  It  need  now  know  where  the  previous 
routine  is  nor  even  where  the  stack  is  located.  A series  of  stack 
handling  routines,  which  should  appear  quite  familiar  to  many  small 
calculator  users,  provide  an  array  of  capabilities,  including  the 
ability  to  "PUSH"  a number  on  the  stack,  "POP"  it  off,  duplicate  it, 
"SWAP"  the  top  two  numbers,  locate  a number  some  distance  into  the  stack, 
and  copy  it  on  top  of  the  stack,  etc.  Additionally,  a variety  of  logic 
functions  familiar  to  the  minicomputer  user  are  provided  including  OR, 
AND,  shift  left,  shift  right,  greater  than,  less  than,  etc.,  etc. 

Input/output  (I/O)  is  normally  accomplished  using  the  stack  in 
conjunction  with  the  "IMDEVICE"  or  "OUTDEVICE"  commands.  For  example, 
to  take  data  from  a device  located  at  I/O,  port  7,  the  number  seven  is 
"pushed"  onto  the  stack  and  INDEVICE  is  called.  INDEVICE  "pops"  the 
top  number  from  the  stack  ("7"),  goes  to  this  I/O  port,  takes  in  a num- 
ber and  "pushes"  the  number  on  the  stack.  OUTDEVICE  functions  in  a 
similiar  manner,  requi ring  the  number  to  be  sent  to  the  desired  device 


to  be  "pushed"  onto  the  stack  followed  by  tlie  device's  I/O  port  address. 
Hence,  to  send  the  number  131  to  device  11,  the  number  131  is  pushed  on 
the  stack  followed  by  11  and  than  OUTDEVICE.  This  "pops"  the  top  number 
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(11)  from  the  stack,  uses  it  as  the  output  port  and  then  sends  the  num- 
ber 131  to  that  location. 

To  appreciate  the  ease  with  which  real  programs  can  be  written,  a 
few  examples  will  be  considered.  A trivial  program,  called  SOUllD,  which 
rings  the  teiminal  bell  three  times,  miglit  be  written 

; SOUND  BELL  BELL  BELL  ; 

The  colon  denotes  changing  from  EXECUTE  to  COMPILE  mode.  After  typing 
the  name  of  the  new  routine,  in  this  case  tobecalled  "SOUND",  typing  the  name  of 
I the  earlier  defined  routine  ('BELL'  - a previously  defined  simple  pro- 

‘ gram  to  ring  the  terminal  bell)  initiates  a dictionary  search  to  locate 

i 

! this  routine's  starting  address  which  subsequential ly  is  entered  three 

j times.  The  resulting  'SOUND'  routine  contains  machine  code  calls  to 

I 

I the  'BELL'  routine  which,  itself,  is  composed  of  machine  code.  Of 

i course,  'SOUND'  '-I’lild  also  have  been  defined  using  a DO-LOOP,  i.e. 

I ; SOUND  3 1 DO  BELL  LOOP  ; 

j where  the  numbers  three  and  one  set  the  upper  and  lower  indices.  If  it 

were  desirable  to  change  the  actual  number  of  bell  rings  from  some  other 
program,  this  value  could  be  defined  as  a VARIABLE--let' s call  it  NOISE. 

3 VARIABLE  NOISE 

In  this  case,  the  number  three  is  first  pushed  on  the  stack,  VARIABLE 
transfers  the  top  number  on  the  stack  (the  three)  to  a dictionary  lo- 
cation named  NOISE.  If  SOUND  were  now  defined  as: 

: SOUND  NOISE  0 1 DO  BELL  LOOP  ; 

the  bell  would  again  ring  three  times.  In  this  case,  when  the  vjord 
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NOISE  is  encountered,  its  address  is  pushed  on  the  stack,  the  0 is  a 
simple  program  which  goes  to  the  address  indicated  on  the  top  of  the 
stack  (that  of  fJOlSE)  and  replaces  it  with  the  actual  value  located  at 
that  address  (the  number  three).  At  any  future  time,  the  value  of  a 
VARIABLE  can  be  clianged  by  "pushing"  the  new  value  onto  the  stack,  fol- 
lowed by  the  address  of  the  variable  to  be  changed,  getierated  by  its 
name  and  an  exclamation  mark.  To  change  NOISE  to  5, 

5 NOISE  ! 

a number  five  is  pushed  onto  the  stack,  NOISE  pushes  its  address  on  the 
stack,  and  ! goes  to  the  address  indicated  by  the  "top"  number  on  the 
stack  and  deposits  the  next  number.  Now  sound  would  ring  the  terminal 
bell  five  times. 

A much  less  trivial  program  which  could  be  written  to  scan  and  take 
data  from  a monochromator  equipped  with  a DENCO  SI12A  stepper  motor  con- 
troller (1)  (the  Sn2A  takes  a parallel  number  as  an  address,  sends  one 
of  two  stopper  motors  to  this  location  and  outputs  an  arrival  flag  when 
the  address  is  reached)  is  given  in  Figure  6.  Assume  that  the  experi- 
mental system  is  configured  so  the  SM2A  is  at  I/O,  port  5 and  an  analog 
to  digital  converter  to  acquire  data  is  at  I/O,  port  7.  Let  us  assume 
that,  initially,  a scan  is  designed  from  a starting  stepper  motor  lo- 
cation of  2000  to  a final  location  of  5000,  taking  data  every  20  steps. 

Uhile  the  code  might  look  a little  strange  at  first,  it  quickly 
becoiDes  very  easy  to  work  with.  The  SCAN  program  of  Figure  6 could 
be  combined  with  other  modules  as  shown  in  Figure  5 to  perform  some 
more  complex  experimental  function.  Each  module  of  the  program  can  be 


easily  tried  out  to  ensure  that  it  is  operational  before  proceeding 
with  the  next. 

Presently,  CONVERS  is  being  used  in  the  authors'  laboratories  for 
a variety  of  spec trochemi cal  investigations,  including  laser  excited 
optoacoustic  spectroscopy  (Figure  7)  and  inductively  coupled  plasma 
optical  emission  spectroscopy  (Figure  8).  Rather  complex  interactive 
control  and  data  acquisition  programs  have  been  easily  implemented. 

Memory  requirements  and  operating  speed  have  been  found  to  be  far  superior 
to  conventional  approaches.  Additionally,  new  system  users  have  en- 
countered almost  no  difficulty  in  utilizing  previously  developed  software 
even  when  documentation  was  vague. 

The  authors  hope  that  this  short  introduction  to  only  a few  of 
the  concepts  employed  in  CONVERS  will  generate  interest  in  its  capabi- 
lities. A much  more  complete  discussion  is  available  in  the  form  of  a 
user's  manual  (3)  available  from  the  authors. 

The  devolopmcnl  of  the  CONVERS  system  was  partially  supported  by 
the  Office  of  Naval  Research  and  a Alfred  P.  Sloan  Foundation  Research 
Fellowship  to  M.  Bonner  Denton. 

(1)  C.  Moore.  Astron.  Astrophys.  Suppl . , 15  (1974)  497. 

(?)  M.  B.  Denton,  J.  D.  Mack.  M.  W.  Routh  and  D.  R.  Swartz,  American 
Laboratory.  B,  59  (1976). 

(3)  CONVERS:  AN  INTERPRETIVE  COMPILER,  developed  by  Scott  B.  Tilden  and 
M.  Bonner  Denton,  Department  of  Chemistry,  University  of  Arizona, 
Tucson,  Arizona  85721. 
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ticiufc  I:  The  interpretative  cycle  of  common  types  of  languages 
such  us  BASIC.  After  examining  each  command  in  the  source  file,  the 
interpreter  searches  for  and  branches  to  the  corresponding  block  of 
machine  code;  thus,  program  execution  always  remains  within  the  in- 
terpret''* . 


etc. 


Fi  gure  3 . 


The  'threaded'  code  acproach  used  in  COIIVERS.  Note  that 
the  nov  nf  logic  threads  its  way  in  a very  non-linear 
fashion. 
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Figure  4.  Memory  map  of  the  CONVERS  dictionary. 
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Figure  5. 


If  a previously  defined  program  name  (ACQUIRE)  is 
entered  when  in  EXECUTE  mode,  a dictionary  search 
takes  place  locating  the  ACQUIRE  entry.  Once  found, 
this  entry  contains  all  the  required  machine  code 
and/or  calls  to  addresses  of  other  previously  compiled 
machine  code  modules  to  completely  execute  the  desired 
function. 
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Figure  3.  A schematic  of  the  inductively  coupled  plasma  emission  spectrometer  in  which  the 
microcom.puter  is  used  to  control  radio  frequency  power  and  'flame'  positioning 
as  well  as  to  monitor  light  intensity. 


Figure  Captions 


Figure  7.  The  optoacoustic  experiment  in  which  a micro- 
computer is  used  to  control  laser  wavelength 
and  to  monitor  laser  power  and  optoacoustic 
signal. 

Figure  8.  A schematic  of  the  inductively  coupled  plasma 

emission  spectrometer  in  which  the  microcomputer 
is  used  to  control  radio  frequency  power  and 
'flame'  positioning  as  well  as  to  monitor  light 
intensi ty. 
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